A remote boot client computer boots off a server computer connected to the client through a network rather than booting from the local boot drive. Everything that would normally be stored on the local boot drive is instead stored in a client-specific location, or store, on the server. When a remote boot client computer starts up, typically the boot ROM (read-only memory) in the client requests a small bootstrap code module known as a "loader" from the server which the server transfers over the network to the client. The loader executes on the client computer and causes the server to transfer the operating system executable and other files needed to start the system. The operation system executable and other files are collectively referred to as the "boot files." Once the operating system is up and running on the client, it communicates over the network as needed to read and write other files from and to the client-specific store that it would normally read and write from and to the client computer's hard drive if booting locally.
Because the data used to boot the client is stored is on the server, it important that the data be as secure as the data would be if it were stored on the local boot drive. This means that it must be protected from viewing and modification by unwanted users, both while it resides on the server and while it is being transferred across the network. Typically, the network protocol used to transfer the loader and the boot files to the client computer is a simple protocol, such as TFTP (trivial file transport protocol), which does not provide security services. A simple, unsecured protocol generally means that any boot file that the loader downloads from the server for one remote client computer will be easily readable by any other client computer on the network. Thus, current remote boot operations present major security issues.
The lack of security in the transfer protocol makes it is easy for a rogue user with access to the network to capture the loader and/or boot files as they are being downloaded from the server to the client. The rogue user can then modify and re-send the modified files to the client. Such an operation is known as "spoofing." A client machine that has been spoofed is unaware that the loader and/or boot files are not coming from the legitimate boot server. At best, the rogue user inserts invalid bits into the loader and/or boot files that prevent them from loading. At worse, the rogue user can cause the loader or boot files to operate in a manner other than what was intended. For example, the loader could be modified to ask the user for a password, and then rebroadcast the password on the network without the user's knowledge. Additionally, the boot files themselves can contain password data or other sensitive material which can be captured by the rogue user.
Another issue with remote booting is that a rogue user can set up a computer to pretend to be either the client or server by observing the network traffic between client and server when they boot. On the client side, the rogue user programs a rogue computer to imitate the legitimate client when booting. The server is unaware that it is not communicating with the legitimate client computer and the server gives the rogue computer access to the legitimate client computer's client-specific store. Furthermore in this case, the server would also give the rogue computer access to any other files on the server that the legitimate client has permission to view. On the server side, the rogue user programs the rogue computer to imitate the legitimate server. The rogue server then sends down modified binaries to a legitimate client. Such modified binaries can, for example, request the user's password and store the entered password for later use.
Once the client computer is booted up, more sophisticated protocols are available to ensure integrity and encryption of files passed between the client and the server. One example is the IP (internet) security protocol known as "ipsec." However ipsec requires that the client and server exchange an encryption key between the two computers. If the encryption key itself is sent over an unsecured network, the security of ipsec is compromised.
Therefore, there is a need to secure the remote boot process which also provides a mechanism for a client and server to exchange a shared encryption key using the secure remote boot process.